fix(create,stream,lib): correct stream rate, recipient guard, stream ID, and deposit total - #379

…col#379 merge

The conduit-protocol#379 merge left lib/soroban.ts non-compiling: invokeContract's body
had a stray fragment of an inlined poll loop (referencing an out-of-scope
`status`, plus a leftover `}, { context, signal })` from the withRetry
call) wedged between the submit step and the real
`return pollForConfirmation(...)`. tsc bailed with 'Declaration or
statement expected', which is why every downstream CI job was red even
past npm ci.

- invokeContract: drop the mangled fragment; it already returned
  pollForConfirmation(hash, ...).
- pollForConfirmation: finish the conduit-protocol#362 change it was mid-refactor on —
  return InvokeContractResult ({ hash, returnValue }) instead of a bare
  string, capturing status.returnValue on SUCCESS so callers like
  createStream can read the assigned stream_id.
- Export resetFeeStatsCache() and call it in soroban-pipeline.test's
  beforeEach — the module-level fee cache (intentionally shared across
  invokeContract calls) was leaking between test cases.
- Update soroban-pipeline / stream / tokens tests for the new
  InvokeContractResult shape and the flags-first field parsing order.

…solate test state

soroban.ts was broken since conduit-protocol#379: duplicated poll logic with a stray
status check left the file syntactically invalid and pollForConfirmation
still returned string instead of InvokeContractResult. Make poll return
{ hash, returnValue } on SUCCESS and { hash } on pending timeout so
create_stream's stream_id surfaces correctly, and clean up the stray
block. Also clear the inclusion-fee cache on resetServer / via
__clearFeeStatsCache so fee-stats tests don't leak cached p70 across
cases.

Tests: update soroban-pipeline mocks to expect object shape, fix
tokens.test mock type, add checkAllowance RPC-failure distinguishing
test, fix stream.test missing-field order, and mock
checkRecipientExists in create/page tests with debounce-aware waits.

* fix(tokens): distinguish RPC failure from insufficient allowance in checkAllowance

checkAllowance previously swallowed getAllowance RPC/network errors and
returned { hasAllowance: false }. The create-stream flow keys off
hasAllowance to decide whether to prompt an SEP-41 approve(), so a
transient hiccup incorrectly triggered an extra signed transaction and
fee even when allowance was already sufficient.

Return { hasAllowance: undefined, error } on failure so callers can
distinguish 'checked, insufficient' (hasAllowance === false) from
'couldn't check' (hasAllowance === undefined) and retry the read
instead of defaulting to needs-approval. Update AllowanceResult docs
accordingly.

* fix(soroban,tests): restore invokeContract returnValue plumbing and isolate test state

soroban.ts was broken since #379: duplicated poll logic with a stray
status check left the file syntactically invalid and pollForConfirmation
still returned string instead of InvokeContractResult. Make poll return
{ hash, returnValue } on SUCCESS and { hash } on pending timeout so
create_stream's stream_id surfaces correctly, and clean up the stray
block. Also clear the inclusion-fee cache on resetServer / via
__clearFeeStatsCache so fee-stats tests don't leak cached p70 across
cases.

Tests: update soroban-pipeline mocks to expect object shape, fix
tokens.test mock type, add checkAllowance RPC-failure distinguishing
test, fix stream.test missing-field order, and mock
checkRecipientExists in create/page tests with debounce-aware waits.

The conduit-protocol#379-merge breakage this PR set out to repair (lib/soroban.ts
invokeContract, app/create timeout helper) is already fixed on main via
later merges, so every conflicting hunk resolves to main's version and
the merge is a no-op.

…epair

fix: repair lib/soroban.ts + app/create mangled by the #379 merge